1. The Field of the Invention
The present invention relates to accessing schematized contact data. More specifically, the present invention relates to utilizing contact data controls to simplify access to schematized contact data.
2. Background and Relevant Art
As the computer industry continues to develop new and efficient means for communicating with contacts are becoming a reality. It is now commonplace, for example, for people to use their personal computers to communicate via e-mail, facsimile, instant message (IM), telephony, video teleconference (VTC), and so forth. This development of enabled communication through computerized devices has greatly enhanced the need for applications to store the contact information that is required for enabling communication and corroboration between contacts.
Contact information is generally referred to herein as information that can be considered relevant for contacting, accessing, corresponding with or otherwise communicating with a contact. Contact information may include, for example, the names, aliases, telephone numbers, e-mail addresses, IM addresses, home addresses, and web addresses of a contact. Contact information can also refer to other types of information such as a real time status, location or disposition of a contact. For example, information indicating a contact is currently connected to a network or on a telephone line may also be broadly construed as contact information. Because there are so many different types of contact information, it can be difficult for anyone to remember all of the contact information that is associated with the various contacts that they communicate with. The difficulty in remembering contact information is even further magnified by the fact that different applications require different types of contact information and sometimes different formats of contact information.
Accordingly, many applications are configured to store this information so that users do not have to commit it to memory. For example, e-mail applications typically utilize directories that are configured for storing the e-mail addresses of contacts that can be e-mailed. Likewise, telephony applications typically utilize directories for storing telephone numbers of contacts that can be called telephonically. Other examples of applications that store contact information include time management applications, instant messaging applications, network gaming applications, business directory applications, VTC applications, and so forth.
In order for a user to obtain the contact information that will be used by a particular application, such as, for example, to initiate a communication or to fill out a form, a user can query a contact information directory that is associated with the application. Accessing a contact information directory, however, is somewhat undesirable because it can increase the total amount of time that is required of the user. Even when the contact information is already known, the delay in time it takes to manually enter the known contact information can also be undesirable.
Contact information directories are typically configured to store only limited amounts of relevant information. For example, some contact information directories are configured to store only contact information specifically required by a corresponding application (e.g., a contact information directory associated with a telephony application may be configured to only store the telephone numbers and not e-mail addresses). Limiting the amount of contact information in a contact information directory can reduce the complexity of a corresponding interface, resulting in efficient access to contact information that is relevant at a particular time. For example, a telephony interface can provide simple and efficient access to telephone numbers.
The use of contact directories also extends to devices that are not considered traditional computers. For example, many telephones, facsimile devices, and photocopying devices also include contact directories for storing contact information that may be used to perform a desired function such as initiating a telephone call, a facsimile transmission, or a telecopy transmission.
Despite the benefits provided by existing contact management systems, the large variety of specialized and disparate contact information directories that are associated with the various applications and devices can make it difficult for users to quickly access all of the available contact information that corresponds to a particular contact. This is particularly true when considering that some of the disparate contact management directories contain different contact information.
One reason disparate contact information directories are problematic is that use of disparate contact information directories can increase the difficulty of identifying all available means for communicating with a contact. That is, a user desiring to access contact information may be required to separately access a number of different contact information directories (through a number of different interfaces) to obtain all the desired contact information. For example, it may be necessary to access a telephone directory to obtain the home or cell telephone number for the contact, an e-mail directory to obtain a primary e-mail address for the contact, a business directory to obtain the business telephone number, and business e-mail address of the entity, and so forth.
Having disparate contact information directories can also be problematic for obtaining different types of contact information about different contacts. For example, it may be desirable to view the e-mail address of a first contact, the business telephone number of a second contact, and the cell telephone number of a third contact. If the desired contact data for each of the different entities is located in a different contact management system of different applications, then each application will have to be accessed to obtain the desired information, thereby requiring the undesirable expenditure of time and resources.
Searches and queries for specific contacts or contact information must also be performed separately through corresponding interfaces for accessing each of the various contact directories. It will be appreciated that this can be particularly problematic when a user has forgotten in which of the contact directories the contact information is stored.
To overcome some of these problems, some contact management systems are configured to redundantly store contact information that is not necessarily required for use by the corresponding application. For example, an e-mail directory may be configured to store the addresses, phone numbers and other information about the various contacts, even though this information is not required to enable e-mail communications.
The variety of directories and corresponding storage capabilities, however, can vary from one application to the next, thereby increasing the difficulty for users to know which of the contact information can be duplicated in each of the different directories. Furthermore, even when it is possible for portions of the contact information to be redundantly stored in each of the different contact directories, such redundant storage would represent undesirable and unnecessary expenditure of computing resources.
Yet another problem with redundantly storing contact information within existing contact directories is that it can be difficult to propagate changes to the contact information throughout all of the various contact directories that are storing the modified contact information. In particular, the separate storage of the contact information in each of the directories necessitates that the change to the contact information be entered into each of the directories. Otherwise, the contact information that is available will be inconsistent and possibly incorrect.
Another problem with existing contact management systems is that because they are so specialized, they fail to provide very extensive and rich search and view capabilities of the contact information. In particular, most contact management systems are relegated to providing only two-dimensional columns or lists of the stored data. Yet another problem with existing contact management systems is that they do not enable a user to view, create, and edit relationships between contacts. More particularly, existing systems do not enable a user to view the relationships existing between contacts or to create and edit these relationships.
Accordingly, some mechanisms for utilizing a common concept of a contact across a number of applications have been developed. Contacts are created and stored with corresponding contact information in such a way that they can be accessed and utilized from a single contact store. For example, contact information can be stored according to a common contact schema that is accessible to applications that store and retrieve the contact information. Applications can be heterogeneous applications that utilize different portions of the contact information or utilize the same contact information in a variety of different ways.
However, due at least in part to the sheer number of different data types and different data formats that may expressed in a common contact schema, it may be difficult for applications to access contact information according to the common contact schema. Further, application designers may have difficulty understanding a common contact schema and designing applications that insure compliance with the common contact schema during execution. Unfortunately, non-compliance with data types and/or data formats expressed in a common contact schema can make corresponding contact information unstorable or inaccessible or may even cause the centralized location to malfunction. Malfunction of the centralized location may prevent a number of other applications from accessing contact information. Accordingly, what would be advantageous are mechanisms for simplifying access to schematized contact information.